Extending Legacy Scripting Languages with Graphical References

ABSTRACT

A graphical data type inference transparently transforms a legacy text-oriented command line interface (CLI) into a graphic-oriented or graphic-aware CLI (G-CLI). A user fuses graphical references with the legacy scripting language by identifying objects using syntax familiar to the user. The objects are presented to the user via a user interface and may be queried/selected by the user. The user issues commands on the selected objects by referencing the graphical selection in a command line within a shell. The graphical selection in short hand is translated into a form operable by a server or computer. The syntax of the legacy command language is extended with operators that operate entirely within the G-CLI. Consequently, the command line used in the shell has an existing operation set, as well as new graphic-based operations.

BACKGROUND OF THE SUBJECT DISCLOSURE Field of the Subject Disclosure

The present subject disclosure relates to computer programming. Inparticular, the present subject disclosure relates to incorporatinggraphical and other references to existing command line syntax.

Background of the Subject Disclosure

Computer interfaces have undergone several iterations from the inceptionof the computer. The first computers had basic input and outputcapabilities requiring mechanical input, printed output, and lots ofuser effort. With the advent of the CRT and keyboard, a command lineinput was conceived, with a text-based output using archaic and complexlanguage syntaxes. Over time, graphical capabilities improved to thepoint that a user did not have to use a command line at all. Instead,entire sets of operations were performed graphically, using inputdevices such as mice, touchscreens, etc. Today, one would behard-pressed to find an average computer user, or even a technicallysavvy home user, using a command line interface (CLI). The graphicaluser interface (GUI) has essentially taken over.

However, certain applications still require the use of commands.Especially for systems administrators who monitor and perform operationson objects in complex file systems, process trees, etc., a GUI depictingthese structures typically has a shell command interface associated withthem to operate upon. Examples include the DOS prompt of a MS WINDOWSsystem, KORN SHELL (ksh), LINUX BASH, etc. Particularly for scriptinglanguages and dynamic programming languages such as PERL and PYTHON, aCLI provides users with much more control of their file system andoperating system and enables a user to easily script a sequence ofcommands to perform a task or execute a program. Often when accessinganother computer or networking device over a network a user will only beable to manipulate the device and/or its files using a command line,CLI, or other text only manipulation.

On the other hand, GUI users have windows that enable a user to easilyview, control, and manipulate multiple things at once, and are commonlymuch faster to multitask with when compared to a command line. Althoughmany command line environments are capable of multitasking they do notoffer the same ease and ability to view multiple things at once on onescreen. Another issue with legacy command line scripting languages isthat when working with very dense system trees and process treesinvolving complex paths, the command lines become unwieldy and complex,resulting in large amounts of code. Particularly with remote control ofa server from a client terminal, dense command syntax, especially inbatches, results in overloading the network and consuming valuablesystem resources.

Past solutions have attempted to fuse GUIs and CLIs by providing aplethora of menu-driven options, and a static set of operations to beperformed on objects that are graphically selected on the GUI. However,performing large complex operations using these methods still does notprovide the speed and ease of use of a traditional CLI. The problems ofeither type of interface still exist today.

Therefore, what is needed is an improved user interface that enablesgraphically represented object structures while taking advantage ofexisting command language syntax.

SUMMARY OF THE SUBJECT DISCLOSURE

The present subject disclosure solves the above problems by uniquelyfusing a graphical layer with a legacy command language interface toform a graphical command line interface (G-CLI). This allows a user tomore efficiently perform operations at varying scales. A scale that canbe identified graphically is able to be seamlessly imported into awell-defined legacy command language. The objects are presented to theuser via a user interface and are arranged in some manner, such as atree. The user issues commands on the selected objects by referencingthe graphical selection in a command line within a shell. The graphicalselection in short hand is translated into a form operable by a serveror computer. The syntax of the legacy command language is extended withoperators that operate entirely within the interface. Consequently, thecommand line used in the shell has an existing operation set, as well asnew graphic-based operations. In other words, the language of thetraditional CLI is extended into the shell of the interface. Therefore,it is easy for a user with existing knowledge of the command language toadopt the new operations/extensions

In one exemplary embodiment, the present subject disclosure is a methodfor interpreting a command line, including presenting a listing of aplurality of objects to a user via a graphical user interface (GUI),receiving a command line from the user, the command line including areference to at least one of the objects in the GUI, and executing acommand on at least one of the objects. The GUI is on a client incommunication with a server. The method further includes receiving thelisting of the plurality of objects from the server, and transmittingthe command line to the server. The listing received from the server isstored on a cache on a client memory, with a coherency protocol beingused to keep the list updated. The method further includes parsing thereference to determine which object the command is to be executed upon,and distilling and normalizing the command line submitted by the userinto a command line that can be executed by the server.

In another exemplary embodiment, the present subject disclosure is acomputer program product for interpreting a command line, the computerprogram product being stored on a computer-readable medium and includinglogic for presenting a listing of a plurality of objects to a user via agraphical user interface (GUI), tagging one or more of the plurality ofobjects with a tag, receiving a command line from the user, the commandline including at least an operator, an argument, and a switch, theargument including the tag, parsing the command line to determine theone or more of the plurality of objects the command is to be executedupon, and distilling and normalizing the command line for subsequentexecution of the command line by a server.

In yet another exemplary embodiment, the present subject disclosure is asystem for executing a command on a plurality of objects, the systemincluding a client having at least a client processor, a client memory,an input device, a display, and a client network interface, a server incommunication with the client, the server including at least a serverprocessor, a server memory, and a server network interface, wherein theserver memory stores a listing of a plurality of objects that can beoperated upon by the server processor, client logic on the client memoryfor receiving the listing of the plurality of objects from the server,presenting the listing to a user via a graphical user interface (GUI) onthe display, receiving a command line from the user, the command lineincluding at least an operator and an argument, the argument including areference to one or more of the plurality of objects, parsing thecommand line to determine the one or more of the plurality of objects,distilling and normalizing the command line for subsequent execution ofthe command line by a server, and transmitting the distilled andnormalized command line to the server. A server logic on the servermemory receives the distilled and normalized command line, and executesthe command line on one or more of the plurality of objects. Theplurality of objects includes one or more of a file, a directory, aprocess, a resource, a node, a network entity, and a user account.

The present subject disclosure also solves the problem of mapping SingleSign On (SSO) authentication and a corresponding wide array ofsophisticated authorization policies to the physical objects manipulatedby scripting languages.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a process flow diagram of a method for interpreting acommand line, according to an exemplary embodiment of the presentsubject disclosure.

FIG. 2 shows a system for providing a graphic-aware CLI (G-CLI),according to an exemplary embodiment of the present subject disclosure.

FIG. 3 shows a G-CLI on a GUI of a client, according to an exemplaryembodiment of the present subject disclosure.

FIG. 4 shows a first graphical data type creation via a G-CLI, accordingto an exemplary embodiment of the present subject disclosure.

FIG. 5 shows a second graphical data type creation via a G-CLI,according to an exemplary embodiment of the present subject disclosure.

FIGS. 6A and 6B show the components of a mobile device operating aG-CLI, according to an exemplary embodiment of the present subjectdisclosure.

DETAILED DESCRIPTION OF THE SUBJECT DISCLOSURE

The following detailed description presents a novel technique forextending legacy scripting languages with graphical references. Thedisclosure describes a graphical data type inference that transparentlytransforms a legacy text-oriented command line interface (CLI) into agraphic-oriented or graphic-aware CLI (G-CLI). Briefly, instead ofentering a typical low-level command directly into a command lineinterface (CLI), a user fuses graphical references with the legacyscripting language by identifying objects using syntax familiar to theuser. The objects are presented to the user via a user interface and arearranged in some manner, for instance, a tree. The user issues commandson the selected objects by referencing the graphical selection in acommand line within a shell. The graphical selection in short hand istranslated into a form operable by a server or computer. This may beperformed by a translation unit embedded within the interface itself.The syntax of the legacy command language is extended with operatorsthat operate entirely within the G-CLI. Consequently, the command lineused in the shell has an existing operation set, as well as newgraphic-based operations. In other words, the language of thetraditional CLI is extended into the shell of the interface. Therefore,it is easy for a user with existing knowledge of the command language toadopt the new operations/extensions. This minimizes the need for a newlearning curve, as well as provides more efficient and simple commandsequences via an optimal coding of textual information that includes theinherent property of graphical representation.

Further, the present subject disclosure extends the legacy CLIgrammar/syntax to support graphical-representation-dependent securitymodels. This is more flexible and offers a granular scope of protectioncompared to existing methods that use the physical object's operatingsystem. For instance, a system administrator may assign permissions tousers on the network for resources based on a graphical layout of theresource tree or table. Other examples are highlighted in the followingembodiments. Finally, the execution of a legacy CLI is transparentlyextended from a single physical unit to a partially orpseudo-distributed execution model. In other words, a portion of thecommand sequence is executed on the G-CLI, either at a client terminalor at a GUI coupled to a server, while the remaining operations areexecuted at the server. Benefits of this model include, among others,early error detection or client-side error detection, and a reduction ofphysical server load and network bandwidth consumption.

As used herein and throughout this disclosure, the term command-lineinterface (CLI) is a mechanism for interacting with a computer operatingsystem or software by typing commands to perform specific tasks.Examples include Microsoft Disk Operating System (MS-DOS), UNIX, KORNSHELL, etc. This text-only interface contrasts with the use of a mousepointer with a graphical user interface (GUI) to click on options, ormenus on a text user interface (TUI) to select options. A command-lineinterpreter (or “shell”) is used to receive, analyze, and execute therequested command. The shell is executed in a text terminal or in aterminal emulator window as a remote shell client. Upon completion, thecommand usually returns output to the user in the form of text lines onthe CLI. This output may be an answer if the command was a question, orotherwise a summary of the operation.

At its most basic, a “command line” includes the command or directivethat informs the computer of what operation is to be performed, followedby an argument, and any optional switches or flags. The argumentidentifies the object(s) that the command is performed upon, and theswitches modify or append to the default behavior of the command. Forinstance, the Unix shell command line “cd /home/pete” changes the user'splace in the directory tree from their current position to the directory“/home/pete”. “cd” is the command and “/home/pete” is the argument. AnMS-DOS command to display all content within a current directory couldbe “dir /a” where “dir” is the operation and “/a” is the switchindicating all content. Other combinations of directives, arguments, andswitches are possible.

An object is any resource, item, or node within an operating system thatcan be represented graphically and can be operated upon by a command.This includes operating system structures, such as files anddirectories. Objects are represented within a graphical user interfacein the form of a tree. Examples of objects that may be graphicallyrepresented in a tree include operating system structures, resources(such as network resources, printers, etc.), processes, network nodes,routers, and so on. Associated with each of these objects are operationsthat manage them, and each operations is associated with the commandline interface.

A command line extension, or “extension”, for the purposes of thepresent subject disclosure, is an additional argument or switch to theexisting syntax of legacy command languages. The extension includesreferences to aspects of a graphical user interface, such as a locationon the GUI, a color within the GUI, and “tagged” objects within the GUI.“Tags” may be assigned to objects manually by the user before they areused in the command line. The command line interpreter converts theextension into arguments/switches that are usable by the operatingsystem.

For the following description, it can be assumed that mostcorrespondingly labeled structures across the figures (e.g., 132 and232, etc.) possess the same characteristics and are subject to the samestructure and function. If there is a difference between correspondinglylabeled elements that is not pointed out, and this difference results ina non-corresponding structure or function of an element for a particularembodiment, then that conflicting description given for that particularembodiment shall govern.

FIG. 1 shows a process flow diagram of a method for interpreting acommand line, according to an exemplary embodiment of the presentsubject disclosure. A user 101 operates a client terminal 120. Clientterminal 120 is in communication with server 140, directly or over anetwork. Server 140 is in communication with and possibly includeswithin a server memory one or more resources 160. In operation, clientterminal 120 includes client logic for updating a cached list of objects160 from server 140. This may occur by transmitting a request S171 forthe latest copy of the list. Server 140 transmits S173 the copy of thelist to client terminal 120. Step S171 is optional; server 140 maytransfer S173 the copy of the list to client terminal 120 based uponlogic on server 140 itself. This can happen, for instance, anytime aprocess or operation is performed on object(s) 160, thereby modifyingthe list. In some exemplary embodiments, the list transmitted in S173includes a plurality of attributes or meta-data for each object.

Client terminal 120 then displays S175 the list to user 101 via a GUI ona display coupled to client terminal 120. The list may be arranged as atable, a tree, a graph, or any type of visual representation known inthe art. Since “object” has been defined as any file, directory,resource, process, node, etc., the plurality of objects is graphicallyrepresented in any convenient format. The graphical representation mayfurther be constructed based upon the meta-data for each object asreceived from server 140. The GUI on client terminal 120 has a searchfeature that allows user 101 to refine/restrict the displayed list tospecific items. The user submits a query S177 to display only certaintypes of objects, for instance, objects modified after a certaindate/time combination, or objects larger than a specified size. Logic onclient terminal 120 processes the list S179 by comparing the user'squery with attributes of the objects, and generates a refined list to bedisplayed S181 to user 101. The user can further tag the search resultswith a specific identifier, as will be further explained below. Ineither case, now the user is ready to submit a command to be executed onthe selected objects/refined list.

The user submits a command S183 via a shell or a command-line interface(CLI) displayed in conjunction with the GUI on client terminal 120. Theuser constructs the command line just like a traditional legacy commandline, such as Perl, Python, korn shell (ksh), or similar scriptinglanguage. However, instead of typing in traditional arguments referringto a name or attribute of each object, the user instead types in orincorporates into the command line a graphical reference, or a tagcorresponding to the refined list/selected objects. In other words, areference to a plurality of objects is condensed into a single graphicalreference or tag that all selected objects have in common. The graphicalreference may be embedded into the command line either by typing or viaa mouse selection, for instance, by dragging and dropping an objectselection into the command line. Syntax extensions for graphicalreferences may be learned by the user so that they can type thereference into the command line; however, these extensions are simpleand mimic the existing syntax, as is shown in the following examples.

Logic onboard client server 120 parses S185 the received command line todetermine the objects being operated upon, and distills and normalizesthe command line so that it is able to be executed by server 140. Thelogic then transmits S187 the normalized command line to server 140 forexecution. This process may be carried out by a translation unit withinclient terminal 120, or within the shell itself. At server 140, logiconboard server 140 executes S189 the command line. The command linemodifies or performs the request operation S191 upon resource 160.Server 140 reports the results S193 back to client terminal 120. Thisreporting may additionally include a new and updated list of objectsreflecting the result of the operations performed in S191. In someembodiments, upon executing the command, server 140 updates a pluralityof client terminals with a refreshed list of objects and theirattributes. This ensures that any client-side programming is valid andproperly executed when submitted to the server. In another embodiment,routers on a network can be acted upon using the proprietary CLI of therouter, such as the Cisco CLI. In this case, a subset of the Cisco CLIis provided into the G-CLI, and extended to allow importing graphicalselections. The translator then translates the graphical selections intoappropriate syntax before submitting the command to the server.

FIG. 2 shows a system 200 for providing a graphic-aware CLI (G-CLI),according to an exemplary embodiment of the present subject disclosure.A client terminal 220 is in communication with server 240, directly orover a network. Server 140 is in communication with a database 241 thatincludes one or more objects that can be operated upon by logic onboardserver 240. In operation, client terminal 220 includes client logic forupdating a cached list of objects 260 from server 240. The list ofobjects 260 includes a plurality of attributes or meta-data for eachobject. A refresh cycle may be programmed into either the client 220 orthe server 240 to update any changes occurring in objects 260.Alternatively, when a write cycle occurs from one client, all otherclients 220 are refreshed via a push operation from server 240. Thisprocess may be used for disconnected operations, i.e. batch processingof a plurality of commands (or a “batch” of commands) submitted toserver 240 for subsequent execution when connected. This is useful forintermittent connections between client 220 and server 240, forinstance, for a mobile network administrator attempting to performoperations on back-end resources using a remote device. Client terminal220 displays list 260 to a user via a GUI on a display coupled to clientterminal 220. List 260 may be arranged as a table, a tree, a graph, orany type of visual representation known in the art. Since “object” hasbeen defined as any file, directory, resource, process, node, etc., theplurality of objects is graphically represented in any convenientformat. The user may then submit a query to display only certain typesof objects, for instance, objects modified after a certain date/timecombination, or objects larger than a specified size. Logic on clientterminal 220 processes list 260 by comparing the user's query withattributes of the objects, and generates a refined list to be displayed.The user can further tag the search results with a specific identifier,as will be further explained below.

The user then submits a command via a shell or a command-line interface(CLI) displayed in conjunction with the GUI on client terminal 220. Theuser instead types in or incorporates into the command line a graphicalreference, or a tag corresponding to the refined list/selected objects.Logic onboard client terminal 220 parses the received command line todetermine the objects being operated upon, and distills and normalizesthe command line to produce a normalized command line 261 to betransmitted to server 240 for execution. Normalized command line 261does not include the graphical references/tags. Instead, normalizedcommand line 261 is in a form that can be understood and executed by theoperating system stored on server 240. The command line modifies orperforms the requested operation upon the selected/tagged resources.Subsequently, server 240 reports an updated list of objects 260reflecting the result of the operations performed to all clients on thenetwork. These clients, including client 220, cache this information asa point-in-time snapshot of the state of the resources on the server,and a coherency protocol can be used to maintain consistency.

As mentioned above, the G-CLI on the client serves not only to simplifythe code typed by the user, but also to reduce the load on the back-endserver by performing portions of the operations at the client itself. Inother words, the G-CLI on the client is used to identify what is to beperformed, before the operation is transmitted to the server. There maybe many situations where this is useful, for instance, when a systemadministrator desires to restrict access to certain objects based on atime constraint. The user runs a search on the GUI for objects meetingthe constraint, tags or simply displays the objects on the screen, andissues a command line with the argument including the tag or anindicator indicating the contents of the screen. Using the attributes ofeach directory (writeable, etc.), a command may be issued within the GUIto find a set of objects that are graphically selected based on theirattributes, and then the command is transmitted to the server. Theoperations carried out on the server are thereby reduced with the helpof the GUI and the consistent cache state.

FIG. 3 shows a G-CLI on a GUI of a client, according to an exemplaryembodiment of the present subject disclosure. The client includes adisplay 321. Display 321 shows a title 322, a selection box 323, anobject window 235, a tag option 330, a command line prompt 332, and aresults window 334. Object window 325 shows an object list, includingde-selected (clear) objects 327 and selected (shaded) objects 329. Auser may search for objects using any combination of selection box 323and command prompt 332. For instance, a user can select processes, andthen command the GUI to display all processes that occupy a certainamount of system resources, or that were initiated by a specific user.This could be performed using the command line, a mouse selection (suchas a right-click context-sensitive menu), etc. Then, the user inputs acommand into prompt 332 to kill all processes displayed on the screen.Alternatively, the user may tag all displayed processes using tag option330, then load another screen with other processes matching a differentcriteria, tag the second set of results, and then execute a commandincluding the tag as an argument, thereby performing the operation onboth sets of results at the same time.

In another example of a graphical extension on a legacy language, a userselects a plurality of folders 329, and wishes to display the contentsof the folders. In a legacy korn shell (ksh) scripting language, theuser would simply insert “ls−id ${s}” where ${s} indicates theselection. Logic on the client terminal would translate the ${s} into anactual command line including the proper arguments for processing by theserver. In another example, still using the ksh language, a user wishesto test whether the selection is accessible at the current time. Theuser would type in the command line:

if [ -T.v ${s} ]; then print ${s} is currently accessible; else print${s} is currently inaccessible; fi

This is an example of applying a sophisticated security policy inphysical objects, in this case, a file system directory. The virtualoperator is “−T.v ${s}” to test whether or not the selection isaccessible. In this case, the output window 334 would display theresult. In another example, a simple GUI command rewrite is used toavoid a disk write on the server. The user types the command: if [−w${s}]; then echo ${s} is writable; fi

The operator “−w” uses the securely cached state within the GUI (i.e. onthe client terminal) to determine if the selected directory iswriteable. This avoids a costly disk access on the server, savingsystem/network resources and processing power.

One may additionally incorporate color references into the commandlanguage syntax. This adds another dimension of the GUI into the commandline. The command line will be distilled and normalized before beingcarried out as a true operation on the back end server. For instance, auser tags different objects with different colors using the tag option330, then executes a simple GUI command rewrite that exploits both colorand structure of the graphic interface using the command line:

if [ ${s [yellow] } -.v ${s [red] } == 2 ]; then echo Difference indepth between [ ${s [yellow] } and ${s [red] }] is 2; fi

In this case, the virtual operator “−.v” performs arithmetic on “edges”of selections, similar to an image processing logic. Any colordifferences around edges of selections is converted into a quantity,distilled and normalized into a traditional text-based command languagereferencing the selected resources, and the result is output in theresult window 334. This concept can be expanded to edges, or any visualaspect of the object window, as syntax within the extension to thelanguage. For instance, a property of the GUI could assign variables toedges upon loading of the GUI itself. Thickness/color of edges can beincorporated within the extended syntax. Other visual cues will becomeapparent to a person having ordinary skill in the art upon a completereading of this disclosure.

There are several additional applications where the present subjectdisclosure can be applied. For instance, in a large-scale applicationrunning a traditional or cloud-based (virtual) data center, the presentsubject disclosure may be used by a system administrator to updateseveral file-system objects, such as directories and files, bothstatically and dynamically, while the application is running. Similarly,one can conceive a situation where an application is being shut down andthe system administrator desires to get a head start on transferringmodified but quiesced file system objects to a new disk array. Generallya shut-down process takes a very long time to complete becauseapplication processes enormous amounts of data. However, the G-CLI ofthe present subject disclosure in combination with the current cacheenables the administrator to batch-perform these operations within theG-CLI itself, monitor any hypothetical results, and then submit thebatch to the server when the application becomes ready, or when the filesystem objects have completed being modified.

FIG. 4 shows a first graphical data type creation via a G-CLI, accordingto an exemplary embodiment of the present subject disclosure. Briefly,one may create a graphical data type by “overloading” the i/o redirectand append operators when the target is a file with a suffix “.gdt”. Inthis embodiment, it is assumed that the list of object metadata has beentransmitted from the server to the client and is pending G-CLIprocessing. A user specifies a stacked bar chart 400 using a legacycommand line within the GUI itself. For instance, in a korn shell, theuser uses the “cat” command, which reads each file parameter in sequenceand writes it to standard output. An example would be:

cat barchart.gdt NAME|TYPE|CATEGORIES|FILTER|ROWS|CTO|stacked- bar|.doc, .pdf, .ppt| /mnt/cto/documents/ |“Total number” , “Modified inlast 2 weeks” , “> 1MB”

This creates a stacked bar chart type representing the multipledimensions (identified by the CAP labels). Upon execution at the client,a legacy CLI “append” operator (>>) is transparently overloaded toprovide N-dimensional graphic generation capability. Each “find”operation executed in the G-CLI window will produce another dimension inthe graph 400. For instance, the set of command lines:

find /mnt/cto/documents \( -name ‘*.doc’ -o -name ‘*.pdf’ - o -name‘*.ppt’ \) >> barchart.gdt find /mnt/cto/documents -ntime -14 \( -name‘*.doc’ -o - name ‘*.pdf’ -o -name ‘*.ppt’ \) >> barchart.gdt find/mnt/cto/documents -size +1048576c \( -name ‘*.doc’ -o -name ‘*.pdf’ -o-name ‘*.ppt’ \) >> barchart.gdt

Generates additional dimensions in the graphs such as shown in boxes451-453. The results show that 25 “.doc” files have been modified withinthe last 14 days, 85 “.pdf” files exist in total, and 233 “.ppt” filesexist that exceed 1 MB in size. Given these results (and combinationsthereof), the user can select to perform operations on any of theseitems based on the attributes of the files. For instance, the G-CLI cantransparently extend an “&” operator to support a set intersection fortwo attributes. The following command will remove the set of “.doc”files that have been modified in the last two weeks AND that exceed 1 MBin size: “rm $((${CTO.doc[1]} & ${CTO.doc[2]}))”. It should beunderstood that although the present embodiment highlights a ksh script,other scripting languages may also be extended into a G-CLI of thepresent subject disclosure. Generally, a GDT-specific attribute settransparently/automatically is added to a namespace which mimics the“class inheritance” in object-oriented languages. When dealing with agraph or a tree, the attributes for each object such as depth, siblings,parent, ancestor, etc. become part of the namespace. After running thecommand to create the graphic as shown above, the client creates an XMLdocument encoding tag, type, and source, and transmits it to the server.In this way, a graphical data type creation is performed by overloadingthe i/o redirect operator, thereby establishing the bridge between thetext-oriented mode (the lowest abstraction) and the graphic-orientedmode of operation (the highest abstraction). The server would run thecommand, and encode the output into another XML document (or modify theexisting XML) and transmit the document back to the client. The clientwould parse the XML document and generate the resultant graphicalrepresentation on the GUI.

In another exemplary embodiment of the present subject disclosure, anadministrator can operate on a file system or file tree virtually, usingan HTML document object model (DOM) format, or similar visualrepresentation. This is an example of how a client distils andnormalizes a graphic reference in a command line. For instance, a filesystem meta-data is periodically streamed from a server to a client, asdescribed above. The meta-data includes at least an access date/time, amodification date/time, and a creation date/time. The physical objectmodification rate may be represented as a color corresponding to atemperature in a heat map. The graphic object (shown with the particularcolor) is “cooled” at the client via an algorithm that operates on theclient and changes the object color at some specified rate. Logic on theclient then stores the object identifier along with the color in an HTMLDOM format. The legacy CLI can be operated upon the DOM as if it werethe object itself, with DOM-based operations being transformed intophysical object operations using the original CLI syntax.

FIG. 5 shows a second graphical data type creation via a G-CLI,according to an exemplary embodiment of the present subject disclosure.Again, it is to be understood that a server, either on a physical or avirtual (cloud) data center, has transmitted a plurality of attributesto a client, whereby the plurality of attributes includes meta-dataabout a file tree, process tree, or other set of objects stored withinthe server/cloud. The changes to the objects, such as modifications to afile tree, can be encoded as meta-data as a function of time, and theuser will be presented with both the object tree itself, as well as anypotential graphic representations of the meta-data. In the presentembodiment, a DOM is generated of graphical tree 561, with the changesin objects as a function of time being represented by colors on a colormap. The key of the color map is 562. An example of code to generate theDOM is:

<html> <head> <script type=“text/javascript”> function setColor( ) {document.getElementById(“d2”).style.color=“#ff0000”; } </script> </head>

This code reflects a color change in the folder “d2” of object tree 561.A similar code is executed for each object, including files f1, f2, andf3 563. In other words, the client interprets the meta-data stream intoa rate-of-change of the physical file system and represents each objectas a color in the heat map.

Using this feature, an administrator may perform the task of movingquiesced files into a new disk array mode as described above. Byvisually selecting a temperature (color) from array 562 and identifyingthe variable as “$SEL-TEMP” within the G-CLI, the administrator uses thefollowing G-CLI program (based on a legacy ksh, noting that “#” at thestart of a line indicates command input, and “>” indicates commandcontinuation):

# for node in $G_1 >do > if [ ${node.temp} -le $SEL-TEMP ] > then >  my${node.name}...

In other words, the graphical data type inference turns type-specificlegacy CLI “for” operator into a G-CLI graphical data-type operator,with the graph traversal aspects being hidden from the administrator.Behind the scenes, at the client, all information that is required todetermine which branch path to take is contained within the argument(${node.temp} and $SEL_TEMP. The command that is eventually transportedover to the server for actual execution is:

#cat G_1 | while read -r name temp parent child >do >node=(name=$nametemp=$temp parent=$parent child=$child) >...

In other words, on the physical (or virtual) server, the graphical datatype (G_1) is physically represented/normalized as rows in a file,thereby severing all connections to its graphical form on the client.The present subject disclosure automates this process, reducing thenumber of operations carried out on the physical server and the amountof data transmitted over the network. All the administrator sees is theresult of the command, and the corresponding change within the heat map561. Further, familiar and consistent variable syntax provides for othersupported properties, such as “node.parent”, “node.child[ . . . ]”,“node.edge[ . . . ]”, and so on.

Additionally, an administrator can represent the results of the query aspie charts 565-566, using the following code:

#cat piechart.gdt NAME | TYPE | CATEGORIES | FILTER CSO | pie | .doc,.pdf, .ppt | /mnt/cso/documents/ CTO | pie | .doc, .pdf, .ppt |/mnt/cso/documents/ #find /mnt/cso/documents /mnt/cto/documents \( -name‘*.doc’ -o -name ‘*.pdf’ -o -name ‘*.ppt’ \) > piechart.gdt

Executing these commands in a shell window (in this case, ksh) willoutput within the object window (or other window in the G-CLI) both CSOchart 565 and CTO chart 566, with specific colors for each documenttype. The pie chart is transparently generated when the “.gdt” extensionis a target of the legacy redirect operator “>”.

Besides a client terminal, a system administrator may manage criticalsystems via a mobile device. FIGS. 6A and 6B show a G-CLI represented ona display 604 of a mobile device 602. Display 604 is a touch-screendisplay with a virtual keyboard (not shown) for input, however, ahardware keyboard/slide out keypad can be included. A speaker 606,microphone 607, antenna 608 and transceiver 614 enable communicationwith other devices and users across a network. Power supply 610 providespower to CPU 612 and other components, while memory 616 in communicationwith the CPU stores the client logic 618 for generating the G-CLI,performing the functions described above, as well as additional logicfor operating the components of mobile device 602.

As described above, once a GUI search/query is performed, the resultscan be tagged with a particular identifier/tag. This enables performingaggregate operations in an easy manner. Moreover, an administrator/userof the client terminal may further use spoken language to carry out thetasks described above. For instance, a text-to-speech interface canconvert a spoken tag instead of having to verbalize physical file names.By using simple tag names instead of the names of the objects beingselected, the effort of creating command lines to be submitted to aserver is significantly minimized. This is especially useful for certainsituations, for instance, if there is a problem on the server, such asprocesses being spawned at an unbearable rate. An operation could beexecuted to find all operations executed within the last hour. Theprocess is the same as the query and command described above, with theonly exception being that a verbal cue states “kill *tag*”, and theproblem is solved. This, and other operations, may be performed via aG-CLI on a mobile device such as the one described in FIG. 6, or anybrowser, x-window, GUI, portal, etc., on any terminal having inputcapabilities.

The present subject disclosure therefore creates a new paradigm thatseamlessly connects two previously independent environments: browsercontents (i.e. DOM model) and a server-side scripting language. Bymerging the dynamic and interactive capabilities of a traditionalscripting language/domain-specific CLI with the latest advancements inweb graphics, visualization, web security, and speech-to-textconversion, the ability to identify problems visually is vastly superiorto investigating a system using the traditional command window andassociated CLI. In summary, the present subject disclosure provides easeof control of complex systems, faster human decision-making, improvedinteractivity, and lower costs through efficiency and avoidance ofcomplexity.

The foregoing disclosure of the exemplary embodiments of the presentsubject disclosure has been presented for purposes of illustration anddescription. It is not intended to be exhaustive or to limit the subjectdisclosure to the precise forms disclosed. Many variations andmodifications of the embodiments described herein will be apparent toone of ordinary skill in the art in light of the above disclosure. Thescope of the subject disclosure is to be defined only by the claimsappended hereto, and by their equivalents.

Further, in describing representative embodiments of the present subjectdisclosure, the specification may have presented the method and/orprocess of the present subject disclosure as a particular sequence ofsteps. However, to the extent that the method or process does not relyon the particular order of steps set forth herein, the method or processshould not be limited to the particular sequence of steps described. Asone of ordinary skill in the art would appreciate, other sequences ofsteps may be possible. Therefore, the particular order of the steps setforth in the specification should not be construed as limitations on theclaims. In addition, the claims directed to the method and/or process ofthe present subject disclosure should not be limited to the performanceof their steps in the order written, and one skilled in the art canreadily appreciate that the sequences may be varied and still remainwithin the spirit and scope of the present subject disclosure.

What is claimed is:
 1. A method for interpreting a command line, themethod comprising: receiving a selection of a graphical object from adisplayed graphical hierarchical tree listing of a plurality of objects,each object of the plurality of objects graphically representing adifferent operational command to an operating system, to yield aselected object; receiving text, typed by a user, in the command line;receiving the selected object into the command line, to yield a modifiedcommand line input; and executing, by a processor, the modified commandline input as an operation within the command line.
 2. The method ofclaim 1, wherein receiving the selected object into the command linefurther comprises processing user input associated with dragging anddropping the selected object into the command line.
 3. The method ofclaim 1, further comprising: distilling and normalizing the modifiedcommand line input; and executing, by a processor, the selected objectinserted as an operation within the command line.
 4. The method of claim1, further comprising: receiving the displayed graphical hierarchicaltree listing of the plurality of objects from a server; and transmittingthe modified command line input to the server.
 5. The method of claim 1,further comprising parsing one of the plurality of objects according tothe selected object.
 6. The method of claim 1, further comprisingsending a normalized command line to a server for execution.
 7. Themethod of claim 1, further comprising receiving a query to search thedisplayed graphical hierarchical tree listing of the plurality ofobjects.
 8. A system comprising: a processor; and a computer-readablestorage device storing instructions which, when executed by theprocessor, cause the processor perform operations comprising: receivinga selection of a graphical object from a displayed graphicalhierarchical tree listing of a plurality of objects, each object of theplurality of objects graphically representing a different operationalcommand to an operating system, to yield a selected object; receivingtext, typed by a user, in a command line; receiving the selected objectinto the command line, to yield a modified command line input; andexecuting the modified command line input as an operation within thecommand line.
 9. The system of claim 8, wherein receiving the selectedobject into the command line further comprises processing user inputassociated with dragging and dropping the selected object into thecommand line.
 10. The system of claim 8, wherein the computer-readablestorage device stores additional instructions which, when executed bythe processor, cause the processor to perform further operationscomprising: distilling and normalizing the modified command line input;and executing the selected object inserted as an operation within thecommand line.
 11. The system of claim 8, wherein the computer-readablestorage device stores additional instructions which, when executed bythe processor, cause the processor to perform further operationscomprising: receiving the graphical hierarchical tree listing of theplurality of objects from a server; and transmitting the modifiedcommand line input to the server.
 12. The system of claim 8, wherein thecomputer-readable storage device stores additional instructions which,when executed by the processor, cause the processor to perform furtheroperations comprising: parsing one of the plurality of objects accordingto the selected object.
 13. The system of claim 8, wherein thecomputer-readable storage device stores additional instructions which,when executed by the processor, cause the processor to perform furtheroperations comprising: sending a normalized command line to a server forexecution.
 14. The system of claim 8, wherein the computer-readablestorage device stores additional instructions which, when executed bythe processor, cause the processor to perform further operationscomprising: receiving a query to search the displayed graphicalhierarchical tree listing of the plurality of objects.
 15. Acomputer-readable storage device storing instructions which, whenexecuted by a processor, cause the processor perform operationscomprising: receiving a selection of a graphical object from a displayedgraphical hierarchical tree listing of a plurality of objects, eachobject of the plurality of objects graphically representing a differentoperational command to an operating system, to yield a selected object;receiving text, typed by a user, in a command line; receiving theselected object into the command line, to yield a modified command lineinput; and executing the modified command line input as an operationwithin the command line.
 16. The computer-readable storage device ofclaim 15, wherein receiving the selected object into the command linefurther comprises processing user input associated with dragging anddropping the selected object into the command line.
 17. Thecomputer-readable storage device of claim 15, wherein thecomputer-readable storage device stores additional instructions which,when executed by the processor, cause the processor to perform furtheroperations comprising: distilling and normalizing the modified commandline input; and executing the selected object inserted as an operationwithin the command line.
 18. The computer-readable storage device ofclaim 15, wherein the computer-readable storage device stores additionalinstructions which, when executed by the processor, cause the processorto perform further operations comprising: receiving the displayedgraphical hierarchical tree listing of the plurality of objects from aserver; and transmitting the modified command line input to the server.19. The computer-readable storage device of claim 15, wherein thecomputer-readable storage device stores additional instructions which,when executed by the processor, cause the processor to perform furtheroperations comprising: parsing one of the plurality of objects accordingto the selected object.
 20. The computer-readable storage device ofclaim 15, wherein the computer-readable storage device stores additionalinstructions which, when executed by the processor, cause the processorto perform further operations comprising: sending a normalized commandline to a server for execution.